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(54) Method and apparatus for enhancing the portability of an object oriented interface among 
multiple platforms 



(57) The present invention is directed to providing 
an ability to re-host, or port, an object oriented graphical 
user interface implementation from a native window- 
based platform, or environment, to another window- 
based platform, or environment. Exemplary embodi- 
ments abstract any notifications (e.g., events, state 
changes or "interests") which occur in the native envi- 
ronment as behavioral specifications. These behavioral 
specifications, (i.e., traits or protocols) can be used as 
part of a conformance negotiation to determine, during 
the execution lifetime of the graphical user interface, 
whether a particular client side object will conform with 
the behavioral specifications which have been 
abstracted from server side events associated with a 
different object. Where the conformance negotiation 
proves successful, abstract notifications can flow 
between particular instances of objects to model the 
state of the system, rather than using native implemen- 
tations of events. During the execution lifetime, other 
objects can dynamically establish relationships with 
object classes containing abstracted notifications for the 
purpose of receiving the abstracted notifications. 
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Description 

BACKGROUND OF THE INVENTION 
Field of the Invention 
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integrates any of a variety of different hardware and/or software platforms. 
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implementation for use with a specific window-based environment, the toolkit cannot be readily ported from one win- 
dow-based platform .to another. That is, an "event" found in a native window-based platform for which a toolkit was 
implemented can differ significantly in implementation from another window-based platform to which the toolkit is to be 
ported. Further, native implementations are simply not designed with portability to other environments as a goal, such 

5 that platform dependencies are not typically localized or abstracted within the native platform. An "event" defined for 
one platform is usually different in implementation with respect to other platforms in terms of the information which is 
provided (i.e., different semantics), as well as the format with which any such information is provided (i.e., different syn- 
tax). The amount of computer code which must be revised to use a toolkit defined for one window-based platform with 
another window-based platform is therefore excessive and impractical. As such, significant problems exist in porting an 

10 object oriented graphical user Interface from a native window-based platform to another window-based platform (e.g., 
such as porting from the NeXTSTEP environment of NeXT Computer Company onto another window-based platform 
such as the X-Window System™). 

Accordingly, it would be desirable to develop a method by which platform dependencies can be localized and 
abstracted for use with an object oriented graphical user interface, wherein object interactions are defined with respect 

75 to an abstract model-view-controller. For example, it would be desirable to abstract the events received from a window- 
based system so that the primary portions of code used to represent a toolkit of an object oriented graphical user inter- 
face can remain unchanged, and therefore be easily ported to any of a variety of window-based platforms. 

SUMMARY OF THE INVENTION 

20 

The present invention is directed to providing an ability to re-host, or port, an object oriented graphical user inter- 
face implementation from a native window-based platform, or environment, to another window-based platform, or envi- 
ronment. In accordance with exemplary embodiments, any notifications (e.g., events, state changes or Interests") 
which occur in the native environment are abstracted as behavioral specifications. These behavioral specifications, 

25 (i.e., traits or protocols) can be used as part of a conformance negotiation to determine, during the execution lifetime of 
the graphical user interface, whether a particular client side object will conform with the behavioral specifications which 
have been abstracted from server side events associated with a different object. Where the conformance negotiation 
proves successful, abstracted notifications can flow between particular instances of objects to model the state of the 
system, rather than using native implementations of events. During the execution lifetime, other objects can dynamically 

30 establish relationships with object classes containing abstracted notifications for the purpose of receiving the 
abstracted notifications. 

Exemplary embodiments of the present invention thereby create an abstraction layer within the native implementa- 
tion that separates and localizes platform implementation dependencies throughout the toolkit of the object oriented 
graphical user interface. Exemplary embodiments significantly extend the client side model-view-controller paradigm 

35 and its application within user interfaces to reduce the magnitude of the porting task, and to accommodate porting of 
an interface among different window-based platforms. 

Generally speaking, exemplary embodiments of the present invention are directed to a method and apparatus for 
porting a toolkit of a graphical user interface to a window-based platform, comprising the steps of: receiving a native 
notification of a state change from a window-based platform; and representing said native notification as an abstracted 

40 notification during execution of the graphical user interface,: said abstracted notification constituting a behavioral spec- 
ification of the native notification which is independent of implementations specific to said window-based platform. In 
accordance with the present invention, arbitrary implementations of models, views and controllers arbitrarily conform to 
abstracted notifications. Abstracted notifications which have been defined in the object oriented graphical user interface 
toolkit can be implemented using a programming language of the graphical user interface. Thus, a toolkit established 

45 as part of a graphical user interface can be quickly and cost-effectively ported across any of a variety of window-based 
systems. 

BRIEF DESCRIPTION OF THE DRAWINGS 

so The foregoing and other features ol the present invention will become apparent to those skilled in the art upon read- 
ing the following description of preferred embodiments of the invention in conjunction with the accompanying drawings, 
wherein: 

Figure 1 A shows an abstract representation of a modei-view-controller paradigm; 
55 Figure 1 B is an exemplary application of the abstract representation shown in Figure 1 A; 

Figure 2 illustrates an exemplary flowchart for porting a user interface from a first window-based platform to a sec- 
ond window-based platform in accordance with an exemplary embodiment of the present invention; 
Figure 3 illustrates an exemplary system configured in accordance with the present invention for porting a client- 
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side interface from a first window-based platform to a second window-based platform; 

betwes/aMrary instances of objects conforming to a given behav,oral 
specification with other objects conforming to the same behavioral specrfication. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Poire 2 illustrates an exempt 

OncB^iaflorenips na b appreciate, the runtime negotiation can be performed with 

respe* i^oSSi — ** and destroy dynamic ^^^^ ^ 
toSSESL. of the object oriented graphical user interface, as ^^^fZTJuL user inter- 

Thi, in accordance with exemplary embodiments, the model-view-controller paradigm of the graph cal user ime 
iJS^ZlS^^Zi wherein views can express different interests in muKple models and control- 
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lers. The foregoing steps can be repeated via the loops associated with steps 212 and 214 for any number of ongoing 
notifications, until the execution life of the graphical user interface is completed in "End" step 216. 

In accordance with exemplary embodiments, an object oriented graphical user interface is easily and dynamically 
ported to any of a variety of window-based systems. That is, a graphical user interface toolkit can be dynamically ported 

5 from a native environment for which it was originally implemented (e.g., Microsoft™ Windows) to any other target win- 
dow-based platform (e.g., the X window System™), without encountering the traditional difficulties associated with 
rehosting a toolkit from one platform to another. 

In accordance with exemplary 'embodiments, abstractions are used to remove system dependencies upon concep- 
tual and implementation features of the native platfprm that have no direct counterpart in the target platform. The coun- 

w terpart implementation features significantly undermined a traditional rehosting of a graphical user interlace, since the 
features in question were fundamental to the graphical user interface system and were widespread in their deployment 
within the original implementation. Thus, the amount of effort typically required to initially port the implementation code, 
and to maintain it, was quite costly. However, in accordance with exemplary embodiments of the present invention, sig- 
nificant differences between a native platform and a target platform are handled using abstracted behavioral specif ica- 

15 tions to, for example, notify a client-side of window-based system state changes which affect the client-sidei. 

Figure 3 illustrates an exemplary system for implementing the flowchart of Figure 2. The exemplary Figure 3 sys- 
tem 300 includes a server side 302, a client-side 304 and peripheral inputs 306 to the server side, such as a keyboard 
and/or mouse input. Notifications are passed from the window-based platform of the server side to the graphical user 
interface on the client side via an interprocess communication connection 308. In the Figure 3 system, window-based 

20 platform events, such as a keyboard actuation, actuation of an iconified window, or a mouse movement are repre- 
sented (e.g., translated) by the client side toolkit as abstract notifications. 

As described with respect to Figure 2, events of a window-based system are not merely passed to an object of the 
graphical user interface as was the case with traditional systems. Rather, each object of the graphical user interface 
must initially register an interest during a runtime negotiation with abstractions (i.e., behavioral specifications) of one'or 

25 more notifications that can be received from a window-based system. In the Figure 3 example, an event dispatch object 
of the graphical user interface is used to map abstracted notifications from the window-based platform to one or more 
arbitrary objects of the graphical interface that have registered an interest in a particular notification during a runtime 
negotiation. 

in operation, when the event dispatch object receives a concrete event from the window-based platform of the 
30 server-side, it maps this event into an abstract notification, and passes the abstract notification onto one or more objects 
of the graphical user interface. As a result, any objects which initially registered themselves as having an interest in the 
notification will receive the notification. Thus, the event dispatch object constitutes a mechanism for passing the notifi- 
cations to client-side objects. -- 

As those skilled in the art will appreciate, the functionality described above can be implemented on any computer 
35 readable medium. For example, such a medium can be resident in the graphical user interface 304 of Figure 3, or can 
be resident in a computer readable.medium that can be used in conjunction with the graphical user interface 304. in this 
latter case, a computer programmed product 310 can be encoded with a computer program for porting a toolkit of a 
graphical user interface to a window-based platform. The computer programmed product can, for example, include a 
computer readable storage medium 312 for storing data, such as the abstractions of the notifications from the native 
40 window-based platform and/or, a table for mapping events from the target window-based platform to the various 
abstracted notifications. 

The computer programmed product 310 can further include a computer code mechanism embedded in the com- 
puter readable storage medium for causing the computer readable storage medium to execute the computer code. For 
example, the computer code mechanism can include a first computer code device 312 configured for receiving a native 

as notification of a state change from a window-based platform, and a second computer code device 314, coupled to the 
first computer code device, for representing the native notification as an abstracted notification during execution of the 
graphical user interface. As described previously, the native notification can be mapped to one or more abstracted noti- 
fications. The abstracted notifications, in accordance with exemplary embodiments, constitute a behavioral- specifica- 
tion of the native notification which is independent of implementations specific to both the native and the target window- 

so based platforms. 

In the exemplary Figure 3 embodiment, the computer code mechanism can include any number of computer code 
devices. For example, a third computer code device 31 8 can be included for verifying conformance of at least one object 
in the graphical user interface toolkit with the behavioral specification constituted by the abstracted notification. 

The foregoing features will be further illustrated with respect to the following example. Assume that a user activates 
55 a key on the keyboard of the peripheral input 306, This action results in the sending of a keypress event from the win- 
dow-based platform to the graphical user interface on the client-side. The keypress event includes two significant 
aspects: (1) the semantics of the event; and (2) the format, or syntax, of the event. The keypress event is transferred to 
the client side via the interprocess communication connection 308. 
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typedef struct { 

int type; // - - ButtonPress 

unsigned long serial; // serial number of last request processed 

Bool send_event; // synthetically generated 

Display* display; // window server client reference- 

Window window; // the window the event is delivered to 

Window root; // root window of screen 
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Window subwindow; // the window in which the event 

occurred 

Time time; // server timestamp 

int x, // pixel based, origin top left 

int x_root, // screen relative coords 

y_root; 

unsigned int state; // state of keybd modifiers 

unsigned int button; //which button is pressed? 
Bool same_screen; 
} XButtonEvent; 

typedef XButtonEvent XButtonPressedEvent; 
typedef XButtonEvent XButtonReleasedEvent; 
/* constant for "type" field above */ 
#define ButtonPress 4 
/* constants for "state" field above */ 
#define ShiftMask d< <0) 

fdefine LockMask (1<<D 
#define ControlMask (1< <2) 

#define Modi Mask (1<<3) 
#define Mod2Mask (1< <4) ' 

#define Mod3Mask 0<<5) 
#define Mod4Mask (1<<6) 
#define ModSMask (1 < < 7) 

/* constants for "button" field above */ 
#define Button 1 1 
#define Button2 2 
#define Button3 3 
#define Button4 4 
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#define Buttons 5 

in the NeXTSTEP Window System the Button went is defined as follows (for details see 
JlSp 2T by NeXT Computer Inc. Addison Wesley, 1992 ISBN 0-201-62221-1): 

/* EventData type: defines the data field of an event */ 

typedef union { 

struct | /* For mouse events */ 

short reserved; 

short eventNum; /* unique identifier for this 

button */ 

jnt (-1^^ /* click state of this event */ 

unsigned char pressure; /* pressure value: 

0-none, 
255-full*/ 

char reserved 1; 

short reserved2; 
} mouse; 

/* other event type data deleted . for clarity */ 
} NXEventData; 
/* The event record! */ 
typedef struct { 
float x; 
float y; 
} NXPoint; 

typedef struct _NXEvent { 

int type; /* An event type from 

above */ 

NXPoint location; /* Base coordinates in 

window, from lower-left */ 
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long time; /* vertical intervals since 

launch */ 

int flags; /* key state flags */ 

unsigned int window; /* window number of 

assigned window */ 
NXEventData data; /* type-dependent data */ 
DPSContext ctxt; /* context the event came 

from */ 

} NXEvent, 'NXEventPtr; 

/* constants for "type" field above */ 

#define NX_LMOUSEDOWN 1 /* left mouse-down 

event */ 

#define NX_LMOUSEUP 2 /* left mouse-up 

event */ 

#define NX_RMOUSEDOWN 3 /* right mousedown 

event */ 

#define NX_RMOUSEUP 4 /* right mouse-up 

event */ 

#define NX_MOUSEMOVED 5 /* mouse-moved 

event */ 

#define NX_LMOUSEDRAGGED 6 /* left mouse-dragged 

event */ 

^define NX_RMOUSEDRAGGED 7 /* right 

mouse-dragged event V 

^define NX_MOUSEDOWN NXJ.MOUSEDOWN 

/* Synonym */ 

#define NXJvtOUSEUP NX_LMOUSEUP 

/* Synonym */ 
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#define NX_MOUSEDRACCED NXJ.MOUSEDRAGGED 

/* Synonym */ 
/* constants for "flags" field above */ 
#define NX_ALPHASH1FTMASK 

(1 < < 16) /* if alpha 
lock is on */ 
#define NXJHIFTMASK (l<<17) /* if shift key 

is down */ 
#define NX_CONTROLMASK (1<<18) /* if control 

key is down */ 
#define NX_ALTERNATEMASK (1 < < 19) /* if alt key is 

down */ 
#define NX_COMMAN DMASK (1 < < 20) /* if command 

key is down */ 
#define NX_NUMERICPADMASK (1 < < 21) /* if key on 

numeric pad */ 
#def.ne NX_HELPMASK d < < 22) /* if help key 

is down */ 

/* Device-dependent bits */ 

#defihe N X_NEXTCTRLKEYMASK (1 < < 0) 7* control key 

*/ 

#define N X_N EXTLS H I FT KEYM AS K 

(1 < < 1) /* left side 

shift key */ 

tdefine NX_NEXTRSHIFTKEYMASK 

(1 < < 2) /* right side 
shift key */ 

#define N X_N EXT LCM D KE YMAS K 
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10 



(1 << 3) 7* left side' 
command key */ 

#define NX_NEXTRCMDKEYMASK 

(1 < < 4) /* right side 
command key */ 
#define N X_N E XT L A LT KE YM AS K (1 < < 5) /* left side alt 

key */' ■ 

15 #define NX_NEXTRALTKEYMA5K (1 < < 6) /* right side 

alt key */ 
#define NXJTYLUSPROXIMITYMA5K 

(1 < < 7) 7* if stylus is 
in proximity 
* (for tablets) V 
#define NX_NONCOAL5ESCEDMASK 

(1 < < 8) /* event was 
generated with event 
coalescing disabled */ 
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35 

It is apparent from the definitions above that the two implementations differ significantly in both their concrete syn- 
tax and semantics. Thus r these definitions cannot be used in their native form to create an implementation of a graph- 
ical user interface toolkit that is portable between both platforms without comprehensive conditional compilation 
directives to create parallel implementations for each target window system. However, in accordance with exemplary 
40 embodiments of the present invention, a common definition for a button press event can be abstracted that will be port- 
able across both window systems, making the vast majority of the code implementing the toolkit platform independent, 
through the localization of the platform dependent code into a single, or relatively few components of the toolkit. 

Given the concrete window system event notifications defined above, a first step of an implementation according to 
the exemplary embodiments is to define a common abstraction of the concrete events. This example will use the Objec- 
ts tive-C programming language since this is the implementation language used in programming systems such as NeXT- 
STEP and OpenStep (for the X Window System), An abstract event is used to define the event type, its source, and 
other fundamental information common to all event abstractions: 



so 
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©interface AbstractEvent : Object 
{ 

ehum { 

AEButtonPress, 

AEButtonRelease, 

AEMouseMoved, 

// ... 

| eventType; 

SystemEventDispatcher eventDispatcher; // object 

that maps and dispatches 
events from the platform 
window system. // 
unsigned int eventSerial; // serial number 

unsigned long eventTimestamp; // system 
timestamp 

} 

// ... 
@end 



Next, the concept 
platforms: 



of an event associated wHh a "window" is introduced; that is. a concept common to both target 
©interface AbstractWindowEvent : AbstractEvent 



{ 

unsigned int eventWindow; // id of window event 



occurred on 



} 

il ... 
@end 



M* a particuiar abstraction is defined for a button press event, containing information relevant to both target 
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platforms, but with a synthesized syntax and semantics distinct from those found in the concrete events: 



typedef enum { 

AKbdEShiftModifier - (1 < 0), 
AKbdECtrlModifier - (1 < D, 

// ... 

} AKbdEventModifiers; 

©interface AbstractButtonPressEvent : AbstractWindowEvent 

{ 

float eventX; 
float eventY; 
enum { 

ABPELeftButton, 

ABPEMiddieButton, 

ABPERightButton 
} eventButton; 

AKbdEventModifiers eventKbdModifiers; 

} 

//... 
©end 



A hierarchy of abstract window system event objects, recognizable to those skilled in the art, has thus been defined 
as containing a synthesis of the information found in the concrete event systems of the X Window System and the 
NeXTSTEP Window System for mouse button press events. Next, an interface to an object hierarchy is defined that 
allows an arbitrary object (the observer or sink) to express an interest in observing notifications from another object (the 
observee or source) via a particular protocol or interface specification: 

©interface Object(lnterestProtocolRegistration) 

- (Bool) addObserver: (Object *) observer 

forProtocol: (Protocol*) interestProtocol; 

- (Bool) removeObserver: (Object *) observer 

forProtocol: (Protocol*) interestProtocol; 

@end 

A set of protocols is then defined based upon the abstract event definitions. These protocols describe the formal 
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interface between arbitrary objects that may emH and receive notifications of change, in state of the system as repre- 
sented by the abstract event descriptions detailed above. 

©protocol AbstractEventObserverProtocol 
5 . (void) gotEvent: (AbstractEvent*) theEvent 

fromSource: (Object *) theEventSource; 

@end 

©protocol AbstractWindowEventObserverProtocol 
- (void) gotWindowEvent: (AbstractWindowEvent*) 
J5 theWindowEvent 

fromSource: (Object •> theEventSource; 

@end 

©protocol AbstractButtonPressEventObserverProtocol 



25 



- (void) gotButtonPressEvent: (AbstractButtonPressEvent*) 



theWindowEvent 

fromSource: (Object *■> 

30 

theEventSource; 

©end 



35 



40 



Ha^ngdefined these abstract protocols, a "ButtonControl" object that wishes to receive these notifications can be 



defined: 
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©interface ButtonControl : Control 
< AbstractButtonPressEventObserverProtocoI, 
AbstractWindowEventObserverProtocol, 

// ... 
> 

//... 

- (ButtonControl) newButtonControl; 
-(void) dealloc; 

- (void) gotButtonPressEvent: (AbstractButtonPressEvent*) 
theWindowEvent 

fromSource: (Object *) 
theEventSource; 

- (void) gotWindowEvent: (AbstractWindowEvent*) 

theWindowEvent 

fromSource: (Object *) . 

theEventSource; 

// ... 
@end 

Relevant parts of the implementation are then provided: 

©implementation ButtonControl 
- (ButtonControl) newButtonControl 

{ 

This method creates a new instance of a ButtonControl. As a side effect the ButtonControl registers itself with the 
toolkit's "eventDispatcher" object to receive notifications of Button Press events. 

self - [super init]; 



Now, this object is registered with the window system event dispatcher in order to receive the protocol notifications. 



EP 0 822 484 A2 



[[SystemEventDispatcher eventDispatcher] 
addObserver: self 
forProtocol: 

©protocoKAbstraclButtonPressEventObserverProtocol) 

1;. 

return (ButtonControl*)self; 

}' 

- (void) dealloc 
{ 

This method is called to free instances of the ButtonControl. As a side effect, the ButtonContro, removes 
the eventDispatcher object: 

[[SystemEventDispatcher eventDispatcher] 
removeObserver: self 
forProtocol: 

©protocoKAbstractButtonPressEventObserverProtocol) 

1; 

[super dealloc]; 

} 

- (void) gotButtonPressEvent: (AbstractButtonPressEvent*) 
theWindowEvent 
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fromSource: (Object* ) 
theEventSource 

{ 

// this method get invoked when a Button Press occurs 

on this 

// Control ... 

// .... do ButtonControl activation processing here ... 

} 

@end 

Having defined the graphical user interface toolkit objects in terms of these abstract protocols, the "System Event- 
Dispatcher" class is implemented. For the present example, this is the only class in the event subsystem of the graphical 
user interface toolkit that includes window system dependent code: 

©interface SystemEventDispatcher : Object 
+ (SystemEventDispatcher) eventDispatcher; 

- (void) run; 

- (Bool) addObserver: (Object *) observer 
forProtocol: (Protocol*) interestProtocol; 

- (Bool) removeObserver: (Object *) observer 
orProtocol: (Protocol*) interestProtocol; 

- (void) dispatchAbstractEvent: (AbstradEvent*) absev; 
@end 

A class private interface to the SystemEventDispatcher is defined that encapsulates all of the platform dependent 
code: 

©interface SystemEventDispatcher(PlatformDependentStuff) 
©private 

#ifdef X Windows 
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- (XEvent) _nextXEvent; // fetches next XEvent from X 

Window server 
-(void) _mapXEvent: (XEvent* ) xEvent 
OntoAbstractEvent: (AbstractEvent **) returnEvent; 

//... 
#endif 

#ifdef NeXTSTEP 

- (NXEvent) _nextNXEvent; // fetches next N XEvent from 

NeXTSTEP DP5 

- (void) _mapNXEvent: (NXEvent* ) nxEvent 

OntoAbstractEvent: (AbstractEvent **) returnEvent; 

// ... 
#endif 
II... 
©end 

©implementation SystemEventDispatcher 
{ 

II ... 

HashTable* button PressEventObservers; // contains al 
Controls 

// interested in . 

button 
// press events 

hashed by 
// window id. 

II... 

) 

+ (SystemEventDispatcher) eventDispatcher 
{ 
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// create a new instance of a system event dispatcher 
static SystemEventDispatcher* eventDispatcher - nil; 
if (eventDispatcher - - nil) { 

eventDispatcher - [[SystemEventDispatcher 

alloc] init]; 

} 

return eventDispatcher; 

} 

- run 

{ 

// run the event dispatcher, fetching events from the 
system, 

// mapping them from the platform specific form into 
the 

// abstract mapping and subsequently dispatching them 
to all 

//eligble observers ... 
for (;;) { 

AbstractEvent* absev; 

#ifdef X Windows 

[self jnapXEvent: [self _nextXEvent] 
OntoAbstractEvent: &absev 

]; 

#endif 

#ifdef NeXTSTEP 

[self _mapNXEvent: [self _nextNXEventJ 
OntoAbstractEvent: &absev 

1; . 

#endif 
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[self dispatchAbstractEvent: absev]; 

} 

(void) dispatchAbstractEvent: (AbstractEvent*) absev 

// dispatch abstract events to eligible observers 
switch ([absev eventType] { 

// ... 

case AEButtonPress: 

// Find the COntrol associated with the 

window id 

// of the abstract event and dispatch the 

event 

// to it ... 

Control* c - [buttonPressEventObservers 
valueForKey: [absev 
eventWindowJ 

]; 

[c gotButtonPressEvent: absev 
FromSource: self 

1; 

break; 
// ... 

} 

} 

- (Bool) addObserver: Object* observer 

forProtocol: Protocol* interestProtocol 

{ 
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// register observer (if eligble) for particular observer 
protocol 

// ... 

if (interestProtocol - - 
©protocoKAbstractButtonPressEventObserverProtocol) && 

[observer conformsTo: interestProtocol]) { 

// if the observer conforms to the protocol 

save it in a 

// hash table indexed by its window 
identifier. 

[button PressEventObservers 

insertKey: (const void *) [observer 
window]; 

value; (void *) observer 

1; 

} 

// ... 

return (Bool)True; 

} 

a ... 

@end 

©implementation 

SystemEventDispatcher(PlatformDependentStuff) 
#ifdef XWindows 
II ... 

- (void) _mapXEvent: (XEvent* ) xEvent 

OntoAbstractEvent: (AbstractEvent **) returnEvent 

{ 
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// platform dependent code to map system events onto 
event abstractions 
switch (xEvent->type) { 
// ... 

case ButtonPress: { 

XButtonPressedEvent* xPress - 

(XButtonPressedEvent*)xEvent; 
// create a new AbstractButtonPressEvent 
VeturnEvent - [AbstractButtonPressEvent 
new]; 

// here we initialize the member vars of 
the 

// AbstractButtonPressEvent based upon 
the 

// platform dependent information found 
in the 

// XButtonPressedEvent 
II ... 

} 

break; 
// ... 



II ... 
#endif 

#ifdef NeXTSTEP 
II ... 
#endif 
@end 



A simple exemplary "main" program demonstrates a ButtonControl that will receive abslract notifications of button 
presses from the SystemEventDispataher: 
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int main(const int argc, const char **const argv) 
{ 

[ButtonControl newButtonControll; // create a 
ButtonControl 

[[SystemEventDispatcher eventDispatcher] run]; // run 
the dispatcher 



In accordance with the present invention, the abstract notification of behavioral specifications, in conjunction with 
the event dispatch object, provides an ability to runtime negotiate whether a particular object in the graphical user inter- 
face toolkit conforms to the notification, as described with respect to step 208 of Figure 2. The ability to prov.de runtime 
conformance testing, referred to herein as runtime negotiation, allows relationships between objects in a view field ver- 
sus objects in a control or model field to change dynamically during the execution lifetime of the system. In the exem- 
plary figure 3 system, runtime negotiation allows relationships to be dynamically altered (i.e.. established and de- 
established) via a remapping within the event dispatch object. 

To better illustrate the foregoing features, and in particular the runtime negotiation feature, consider two anony- 
mous objects: one in a window-based platform and the other in the graphical user interface. The two objects know only 
of each other's existence and nothing else. The two objects will be referenced herein as a "vendor" and as a customer . 
A vendor 402 and a customer 404 are graphically illustrated in figure 4. 

Assuming that the behavioral specification of the vender includes a protocol which the customer (e.g.. thB customer 
of a client-side application) wants to use. such as a keypress event, the vender must be able to export some notification 
of keypress events to the customer. The customer knows of the vender's existence, and is interested m entering a rurrt- 
ime negotiation to verify its ability to pass information (e.g.. notifications) to the vender. The customer therefore needs 
to know if the vender conforms with the customer's behavioral specifications. 

Given this starting position, the runtime negotiation is initiated by the customer querying the vender as to whether 
it vends the behavioral specification "A" (i.e., the protocol which the customer wants to use). If the vender does not vend 
the behavioral specification "A", the customer discontinues its attempt to establish an information transfer with the 
vender However, if the vender indicates that it does vend the behavioral specification "A", the customer rasters an 
"interest" with the vender for the behavioral specification corresponding to "A". Because the vender supports this behav- 
ioral specification, the customer informs the vender that it wants to participate in this behavioral specification with the 
vender so that the vender can transfer information to a view of the customer, whenever state changes associated with 
this behavioral specif ication occur. 

Once the customer confirms that it wants to participate in the behavioral specification and negotiate with the vender 
to receive notifications regarding state changes. Ihe vender queries the customer as to whether it conforms (i.e.. 
adheres) to the behavioral specification "A". Assuming that the customer does conform with the behavioral specification 
"A", a relationship (i.e.. runtime contract) is established, such that abstract notifications can flow between these two 

"^accordance with exemplary embodiments, at any time during the execution life of the system, the vender and/or 
customer can withdraw from the relationship. That is. either object can remove itself from the relationship. Such a 
removal may be desirable if. for example, the customer completes its job and resigns from the relationshp. If either 
object resigns from the relationship, then new relationships can be established in the manner already described. 

Having described an exemplary runtime negotiation, attention is now directed to an exemplary mapping of objects 
to one another in accordance with the present invention. In this regard, reference is made to Figure 5. wherein an event 
corresponding to the activation of a push button on a display of a window-based system is to be used to trigger an event. 
In accordance with exemplary embodiments, concrete information corresponding to this event is mapped from the win- 
dow-based platform into abstract information by the graphical user interface in the manner described previously. Here, 
a push button 502 is represented in a client-side objecl oriented graphical user interface as an object with corresponds 
to both a view and to a controller of the model-view-corrtroller paradigm. As a view, it is responsible for drawing the push 
button on a display. As a controller, it describes state changes which occur to indicate that the push button is depressed 
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Claims 



55 



1. A method for porting a toolkit of a graphical user interface to a window-based platform comprising the steps of: 

receiving a native notification of a state change from a „, grapnica , use r inter- 

pendent of implementations specific to said window-based platform. 
2 A method according to claim 1, further comprising a step of: 

3. A method according to claim 1, wherein said step of representing a native notification further includes a step of: 
defining said behavioral specification as a functional signature of a window-based platform event. 
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4. A method according to claim 2, further comprising the step of: 

registering at least one abstracted notification with at least one object of said toolkit dynamically during runtime 
execution of said graphical user interface. 

5. A method according to claim 4, wherein said step of registering further includes a step of: 

registering said abstracted notification with multiple objects of said toolkit dynamically during runtime execution 
of said graphical user interface toolkit 

6. A graphical user interface toolkit for use with a window-based platform, said graphical user interlace toolkit com- 
prising: 

an input for receiving native notifications of state changes from a window-based platform; and 
is a hierarchical collection of objects which establish relationships with abstractions of said native notifications 

that are represented as abstracted notifications, said abstracted notifications constituting behavioral specifica- 
tions of the native notifications which are independent of implementations specific to said window-based plat- 
form. 

20 7. A graphical user interface toolkit according to claim 6, further comprising: 

an output for sending said abstracted notifications to the window-based platform. 

8 A graphical user interface toolkit according to claim 6, wherein said hierarchical collection is configured to register 
at least one abstracted notification with at least one object of said hierarchical collection dynamically during runtime 
execution of said graphical user interface. 

9. A graphical user interface toolkit according to claim 6. wherein at least one of said abstracted notifications is regis- 
tered with multiple objects of said hierarchical collection of objects. 

10 A graphical user interface according to claim 8, wherein said hierarchial collection is configured to verify conform- 
ance of said at least one object to said at least one abstracted notification during runtime execution of said graph- 
ical user interface toolkit 

35 11. A graphical user interface toolkit according to claim 6, wherein said toolkit is implemented in a client side of cli- 
ent/server network. 

1 2 A graphical user interface toolkit according to claim 6, wherein said native notifications of state changes in said win- 
dow-based platform are provided to models, views and controllers used to define interactions between said objects 
40 of said hierarchical collection. 

13. A computer readable medium encoding a program of instructions used to execute a method for porting a toolkit of 
a graphical user interface to a window-based platform comprising the steps of: 

as receiving a native notification of a state change from a window-based platform; and 

representing said native notification as an abstracted notification during execution of the graphical user inter- 
face, said abstracted notification constituting a behavioral specification of the native notification which is inde- 
pendent of implementations specific to said window-based platform. 

so 14. A computer readable medium according to claim 13, further programmed to implement a step of: 

including the abstracted notification in at least one object class of the graphical user interface, 

15. A computer readable medium according to claim 13. further programmed to implement a step of: 

55 verifying conformance of at least one object in the graphical user interface toolkit with said behavioral specifi- 

cation during execution of said graphical user interface. 
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